The present invention relates to voice processing systems which connect to multiple telephone lines for call processing applications.
Voice processing systems are very well-known in the art and are used to perform a wide range of functions. For example, a common form of voice processing system is a voice response unit (VRU), which can be installed at a call centre, and can be used to process incoming calls, often as an initial screening process, or when no human agent is currently available. Thus a typical application might be for the call to come through to the VRU, which plays out to the caller a pre-recorded prompt presenting the caller with a set of options. The caller can then select the desired option by pressing a particular dual tone multiple frequency (DTMF) key on their telephone, and the VRU then performs the requested function. One option for example may simply be for the caller to hear more information (eg about ticket availability), whilst another option may result in the caller being transferred to a live agent (eg to make a ticket reservation). The dialogue between the caller and the VRU can be quite complex, for example, the caller may be required to input a range of dates for which information about ticket availability is required.
An example of a voice processing system is the DirectTalk for AIX voice processing system available from IBM Corporation, and described in the manual xe2x80x9cDirectTalk for AIX, General Information and Planningxe2x80x9d, reference number GC33-1840-00, plus the other manuals referenced therein. Like many modern voice processing systems, the DirectTalk system is based on a general-purpose computer (in this case an RS/6000 workstation) with additional hardware and software for the telephony and voice processing functions. (DirectTalk, AIX, and RS/6000 are trademarks of IBM Corporation).
It is possible to develop very sophisticated applications on the DirectTalk voice processing system, using the wide range of supported features which include: speech recognition (normally as a substitute for DTMF input); FAX; voice mail; use of Automatic Number Identification/Dialled Number Identification Service (ANI/DNIS) information that identifies the calling/called number respectively; text to speech conversion; and remote data-base access.
The structure of a conventional voice processing application is shown in FIG. 1, which illustrates an application 200, the DirectTalk software 210, and an operating system 220 all resident on a single workstation. The DirectTalk software 210 is responsible for accepting the state tables and other components of the customer application 200, and executing as appropriate in conjunction with the operating system 220 for the voice processing system to perform the desired functions. In some cases it may be desirable for the application to access data from a remote system 230, which it would do by exploiting the communications facilities of the operating system (in this case the application may interact directly with the operating system, rather than having to use the DirectTalk software as an intermediary).
Applications for the DirectTalk voice processing system are based on state tables, which essentially list the prompts to be played to a caller and the different actions to be performed dependent on the caller response, plus optional custom servers, which allow more direct program control of the voice processing resources. Thus the development of an application requires the construction of one or more state tables, together with associated prompts and any other more specialised items such as custom servers (for example to provide access to a voice recognition resource). The DirectTalk voice processing system provides a graphical programming tool to facilitate application development. It will be appreciated that the need to develop such programming tools is somewhat burdensome for a voice processing system supplier, since the technology is normally outside the core telephony/IVR expertise of the supplier, and the opportunity to recoup investment in such tools is limited.
As previously mentioned, voice processing applications can become quite complex and also are normally bespoke, in that they are particular to each individual installation. Thus it is difficult for a customer to buy an off-the-shelf solution to satisfy their precise voice processing requirements. Rather, they must first purchase the base voice processing system, and then develop the required application.
In many cases, a customer will contract with some third party to provide a total voice processing solution, including the desired application. This third party is often the manufacturer of the voice processing system, because such manufacturer generally has most expertise in developing applications for their system. This approach can be satisfactory where the voice processing application is essentially a stand-alone operation. However, it is becoming increasingly common to integrate such voice processing applications more and more tightly into the core information systems of a business. For example, it may be desirable to try to match the calling number for all incoming calls against a customer database, to retrieve in real-time information which may be of assistance in processing this call. A customer may be reluctant for a VRU manufacturer to perform such integration for a variety of reasons, perhaps because the manufacturer has insufficient expertise in certain areas of software technology, or perhaps simply because for security reasons it may be undesirable to give a third party too much access to business-critical computer systems.
Furthermore, once a customer has used a third party to develop a voice processing application, they may become dependent on that third party for service and maintenance, which can, in some circumstances, have unfortunate cost implications.
An alternative possibility therefore is for the customer to perform its own voice processing application development in-house, since this gives the customer maximum control over the voice processing application. However, this requires customer software engineers to be skilled in application development on the voice processing system. Such skills are often very rare in the marketplace, given that the absolute number of installations of any one type of voice processing system is rather small, and moreover for this reason, it is rather unattractive for software engineers to focus on such skills, given that they may not significantly enhance their employment prospects. In addition, it is often necessary to have specialised telephony knowledge in order to develop such voice processing applications. Thus it may be difficult for a customer to acquire and retain personnel with the suitable skills required to develop and maintain their own voice processing applications.
Accordingly, the present invention provides a voice processing system having means for connecting to multiple telephone lines, and comprising a set of line objects, each associated with one of said telephone lines, and each line object including a set of methods which may be invoked by other objects for performing operations on the telephone line associated with that line object.
The line objects therefore effectively provide voice response server functionality, which may be invoked as and when desired by user applications. Thus the user applications are effectively separated by this client server relationship from details of the voice processing system, unlike prior art systems where the application had to run in the voice processing environment for that particular platform. This separation bring significant benefits, in that the application development is no longer tied to the relevant voice processing environment, but rather can utilise generic programming tools and skills. This makes application development much quicker and more cost-effective, since high quality generic programming tools and skills are much more readily available in the marketplace than IVR-specific tools and skills.
In the preferred embodiment the line object methods include Answer Call, End Call, Get DTMF Key(s) and Play Audio, although a wide variety of other methods could be made available. These methods represent the core functionality of a voice processing system (particularly for interactive voice response), and so map easily onto actions already provided in the underlying voice processing system.
The voice processing system preferably further comprises a set of IVR action objects which invoke the methods of a line object, most conveniently with an IVR action object corresponding to each method of a line object. This allows the IVR action objects to be easily incorporated into user applications, from where they can invoke line object methods. This provides a degree of isolation between the business application and the line object, which is desirable given that in the preferred embodiment the latter are created essentially at the request of the former and are tied to a physical telephone line. Thus the use of the IVR action objects as intermediaries helps decouple the business application from details of the physical telephone lines. Note however than in some cases for performance reasons it may be desirable for business applications to directly invoke methods in the line objects, without going via the IVR action objects.
The preferred embodiment also provides some higher level components as IVR action objects, such as for a Voice Menu or a Voice Form, which can be regarded as compound objects formed from the above lower level IVR actions. Such higher level components are found frequently in user applications, and so providing them in ready-made form facilitates rapid application development.
An important aspect of the present invention is that the IVR action objects may execute on a remote system, interacting with the line objects via remote method invocation. Thus the IVR system can be regarded simply as a remote server, which can be called to provide IVR functionality when required. In this approach, it is clear that the overall system is determined by the requirements of the business application, and these can then be fed down into the IVR components of the application. This is to be contrasted with prior art systems, in which the voice processing application ran essentially as a stand-alone application in conjunction with (on top of) the voice processing environment, and was thus very constrained by the limitations of the voice processing system; it was also difficult to integrate such a standalone voice processing application into the wider corporate computing environment.
The invention further provides a business application system including voice processing functionality for a set of multiple telephone lines, comprising:
business application programming objects;
voice processing component objects integrated with said business application programming objects, to be called when said business application requires voice processing functionality; and
a voice processing server including programming object means responsive to said voice processing component objects to provide the required voice processing functionality.
In the preferred embodiment said programming object means comprise line objects, each line object being associated with one of said telephone lines.
The invention further provides a method of operating a business application including voice processing functionality for a set of multiple telephone lines, comprising the steps of:
providing business application programming objects, said business application programming objects including voice processing component objects;
calling said voice processing component objects when said business application programming objects require voice processing functionality;
providing software server means including voice processing software which interacts with voice processing hardware to perform voice processing functions, wherein said business application objects including said voice processing component objects are independent of said voice processing software, and interact with said voice processing software only via said software server means;
and invoking a method in said software server means by said voice processing component objects, responsive to a call from said business application programming objects for voice processing functionality, wherein said method in the software server means interacts with the voice processing software and voice processing hardware to perform the requested voice processing function.
In the preferred embodiment, said business application programming objects including said voice processing component objects are located on a first system, and said software server means is located on a second system which includes said voice processing software and voice processing hardware, whereby said voice processing component objects and said software server means communicate via remote method invocation. Thus we can see that the logical decoupling of the application from the IVR system has the added advantage that it is now possible to separate these onto different machines, in particular it is no longer necessary for the application to run on the voice processing system itself. This greatly adds to the flexibility and potential efficiency of the overall architecture, and opens the possibility of one business application being able to utilise multiple voice processing server systems.